Method and apparatus for providing fraud detection using connection frequency thresholds

ABSTRACT

An approach provides detection of unauthorized use of data services. A determination is made as to whether connections supporting remote access to a data network are completed. The number of completed connections associated with a selected attribute is tracked over a time period. It is then determined whether the number of completed connections satisfies a connection frequency threshold. A fraud alert is generated if the connection frequency threshold is satisfied.

RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 11/141,377, filed May 31, 2005, which is a Continuation-In-Partof U.S. patent application Ser. No. 10/843,856, filed May 12, 2004,which claims the benefit of priority under 35 USC 119(e) of U.S.Provisional Patent Application 60/470,917, filed May 15, 2003, andclaims the benefit of priority under 35 USC 119(e) of U.S. ProvisionalPatent Application 60/667,310, filed Apr. 1, 2005; the contents of whichare hereby incorporated by reference.

FIELD OF THE INVENTION

The present invention relates to communications systems, and moreparticularly, to fraud detection in remote access of data services.

BACKGROUND OF THE INVENTION

Modern communication services have evolved around advancements made indata networking technologies. Data transport is one form of suchcommercially offered communication services, whereby customers (orsubscribers) have a need to communicate with one another, accessapplications on a host computer or otherwise transfer data from onepoint to another. Further, these users typically require access theglobal Internet with its vast knowledge base and applications. Thepopularity of data services has spawned the fraudulent usage of suchservices, akin to theft of long distance telephony services.Conventional fraud detection techniques have centered around telephonysystems, and thus, are not well suited to fraud prevention in datacommunication systems, which exhibit different characteristics from thatof circuit switched voice calls.

Service providers recognize the advantage of using the existingtelephony infrastructure to provide ready access to data services. Inmany instances, users particularly when not at their offices do not havereadily available access to the corporate local area network (LAN),corporate intranet, or the Internet. Given the modern day reliance one-mail and the Internet, these business users require access to suchresources from various locations throughout the world. To address thisdemand for remote access, service providers have implemented so-called“dial-up services,” whereby a user may access a data network by a using,for example, a modem through a telephone connection. In this manner, auser may obtain a connection to the data network anywhere a reliabletelephone connection is available.

One common example of dial-up access is the manner in which manyresidential and small business users access the Internet by subscribingto an Internet Service Provider (ISP). A user with a computer and amodem can dial a telephone number corresponding to the service providerand obtain a connection through the service provider to the Internet. Ina similar manner, other dial-up access services have been known by whichhost computers may be directly dialed. Types of data transport that maybe accessed in this manner include, for example, an InternationalTelecommunications Union (ITU) X.25 -compliant packet transport,Internet Protocol (IP) transport, or other forms of packetizedcommunications. In most cases, service providers charge fees to usersfor using the communications resources of the service provider andpossibly for accessing a particular host or service.

Another example of dial-up services relates to virtual private networks(VPNs). For a business enterprise having many geographically dispersedlocations and having sporadic communications needs, it can be costeffective to subscribe to or utilize dial-up access to a data networkrather than lease a dedicated line. For example, as employees of abusiness travel, dial-up access provides wide coverage and increases thelikelihood that a traveler can reach needed resources and services ofthe back office. Additionally, dial-up access is useful for occasionalwork-at-home situations.

Unfortunately, the convenience of access to data services has alsostimulated fraudulent usage, resulting in significant loss of revenuefor the service provider. Fraud perpetrators gain access to thetransport network to reach specific hosts and then use the services ofthe host. These “hackers” can breach the security of the information onthe host, and interfere with the operation of the host or attempt otherforms of attacks. Fraud is also committed to gain free access to theInternet or simply to provide data transport without incurring charges,leaving paying users to bear the costs. Further, such unauthorizedaccess (or usage) can overwhelm network resources, even to the point ofinterfering with legitimate communications.

Fraud detection and redress are also complicated by the intricateinterplay of multiple service providers and their partnershiparrangements. For instance, in some areas (notably some countries), agiven service provider may not have a point of presence that isreachable by a local telephone call. To better serve subscribers over awide area of coverage, a service provider will often contract with anintermediate service provider to extend coverage to areas or countriesnot directly covered by the primary service provider. The subscriberconducts communications through the primary service provider by way ofthe intermediate service provider's facilities, wherein the primaryservice provider provides compensation to the intermediate serviceprovider at an agreed upon rate. The intermediate service provider'snetwork is thus referred to as a “partner network” relative to theprimary service provider's resources.

Undoubtedly, when one or many fraud perpetrators gain access to networkresources, the results are costly both for the service provider and thecustomer. A customer (such as a large organization or enterprise) mayfail to notice charges caused by fraudulent use and unwittingly pay forthe use by the fraudster. In another scenario, the costs incurred by thefraudster may be so exorbitant that the customer refutes the bill andthe service provider is left to absorb the lost revenues or reach acompromise with the customer over the disputed billing. As a furtherdetriment, for fraudulent traffic originating through a partner network,the first service provider may be obligated to compensate the secondservice provider even though the first service provider cannot collectcharges arising from the fraudulent use of the network. Additionally,excessive fraud can impact the reliability and/or quality of the network(e.g., saturation of network resources, etc.). The service provider mayalso face loss of customers, who perceive that the service provider isincapable of providing ample network security or cannot properly addressabuse.

Therefore, fraudulent abuse of network resources consumes time and moneyof customers and service providers and may threaten the operation of thenetwork. As a further exposure to the service providers as describedabove, a given service provider experiencing fraud may have to paysettlements to other service providers to whom payment is owed,regardless of the fraudulent nature of the traffic.

Therefore, there is a need for early detection and prevention of fraudwith respect to data communication services.

SUMMARY OF THE INVENTION

These and other needs are addressed by the present invention, in whichan approach for providing detection of fraudulent use of a data call fornetwork access is disclosed. This approach advantageously reduces theheavy cost of fraud associated with data communication services.

According to one aspect of the present invention, a method for detectingunauthorized use of data services is disclosed. The method includesdetermining whether connections supporting remote access to a datanetwork are completed, and tracking number of completed connectionsassociated with a selected attribute over a time period. The method alsoincludes determining whether the number of completed connectionssatisfies a connection frequency threshold. Further, the method includesgenerating a fraud alert if the connection frequency threshold issatisfied.

According to another aspect of the present invention, an apparatus fordetecting unauthorized use of data services is disclosed. The apparatusincludes a communication interface configured to receive information onnumber of completed connections associated with a selected attributeover a time period, wherein the completed connections support remoteaccess to a data network. The apparatus also includes a processorconfigured to determine whether the number of completed connectionssatisfies a connection frequency threshold, wherein a fraud alert isgenerated if the connection frequency threshold is satisfied.

According to yet another aspect of the present invention, an apparatusfor detecting unauthorized use of data services is disclosed. Theapparatus includes means for determining whether connections supportingremote access to a data network are completed; and means for trackingnumber of completed connections associated with a selected attributeover a time period. The apparatus also includes means for determiningwhether the number of completed connections satisfies a connectionfrequency threshold. The apparatus further includes means for generatinga fraud alert if the connection frequency threshold is satisfied.

Still other aspects, features, and advantages of the present inventionare readily apparent from the following detailed description, simply byillustrating a number of particular embodiments and implementations,including the best mode contemplated for carrying out the presentinvention. The present invention is also capable of other and differentembodiments, and its several details can be modified in various obviousrespects, all without departing from the spirit and scope of the presentinvention. Accordingly, the drawing and description are to be regardedas illustrative in nature, and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIGS. 1A and 1B are diagrams, respectively, of a communication systememploying a fraud detection system for supporting remote accessservices, and the layered architecture of the fraud detection system,according to an embodiment of the present invention;

FIG. 2 is a flowchart of a fraud detection process utilizing a baselineusage pattern for determining fraudulent use, according to an embodimentof the present invention;

FIG. 3 is a flowchart of a fraud detection process involvingcategorization of usage patterns into behavioral groups, according to anembodiment of the present invention;

FIG. 4 is a flowchart of a fraud detection process of a single eventexhibiting a long duration, according to an embodiment of the presentinvention;

FIG. 5 is a flowchart of a fraud detection process using an accumulatedduration associated with a host user identifier (ID), according to anembodiment of the present invention;

FIG. 6 is a flowchart of a fraud detection process using an accumulatedduration associated with a host network, according to an embodiment ofthe present invention;

FIG. 7 is a flowchart of a fraud detection process using an accumulatedduration associated with a host origin country, according to anembodiment of the present invention;

FIG. 8 is a flowchart of a fraud detection process of a single eventassociated with an origin country specified as part of a predeterminedlist of countries having a history of fraudulent activities, accordingto an embodiment of the present invention;

FIG. 9 is a flowchart of a fraud detection process based on failedauthentication attempts, according to an embodiment of the presentinvention;

FIG. 10 is a flowchart of a fraud detection process using connectionfrequency thresholds, according to an embodiment of the presentinvention; and

FIG. 11 is a diagram of a computer system that can be used to implementan embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

A system, method, and software for detecting fraudulent use of datacommunication services are described. In the following description, forthe purposes of explanation, numerous specific details are set forth inorder to provide a thorough understanding of the present invention. Itis apparent, however, to one skilled in the art that the presentinvention may be practiced without these specific details or with anequivalent arrangement. In other instances, well-known structures anddevices are shown in block diagram form in order to avoid unnecessarilyobscuring the present invention.

Although the present invention is described with respect to specificexamples of networks and protocols, such as an Internet Protocol(IP)-based network and an X.25 network, it is contemplated that otherequivalent communication networks and protocols can be utilized.

FIGS. 1A and 1B are diagrams, respectively, of a communication systememploying a fraud detection system for supporting remote access servicesand the layered architecture of the fraud detection system, according toan embodiment of the present invention. A data communication system 100includes a fraud detection system (or fraud monitoring system) 101 thatreceives data files relating to monitored activities from a Wide AreaNetwork (WAN) network 103. In particular, the WAN 103 houses datacollection databases 105, 107 that store the data files, which canretrieved by the fraud detection system 101, for example. Alternatively,the data files can be streamed for more expedient delivery of theinformation. The databases 105, 107 include Host Parameter File (HPF)database and a billing database 107, respectively. The billing database107 communicates with a billing server 109 that generates billing datarelating to the communication sessions supported across the WAN 103. Thebilling server 109 also has connectivity to an authentication server111, which regulates, in part, the login procedures for remote access tothe WAN 103. The term “remote access” refers to the communication withthe authentication server 111 for access to the resource of the WAN 103;exemplary remote access mechanisms include dial-up access using atelephone connection.

As seen in FIG. 1A, the WAN 103 can be accessed by a number of end usersvia hosts 113, 115, 117, 119 through a variety of networks and nodes andcorresponding access equipment 121, 123, 125, 127, which can include amodem, a network interface card (NIC) coupled to an access device orcustomer premise equipment (CPE), etc. depending on the particularnetwork (e.g., Digital Subscriber Line (DSL) network, cable network,telephone network, etc.). For example, such networks can include apublic switched telephone network (PSTN) 129, and a partner packetswitched network 131 that is accessible through a gateway 133. Inaddition, the WAN 103 can extend its reach via a host adjacent node 135.One contemplated data service that is provided to the host subscribersis access to the global Internet 137.

By way of example, the WAN 103 supports access to the Internet 137 usinga Remote Authentication Dial In User Service (RADIUS) topology, whichemploys one or more Network Access Servers (NASs), not shown, and one ormore Authentication, Authorization, and Accounting (AAA) servers. In theexample of FIG. 1A, the server 111 can be configured as an AAA server;accordingly, the server 111 receives requests from the hosts 113, 115,117, 119 and authenticates such users. The server 111, as an AAA server,can authenticate the requests locally or forward the request to anotherAAA server for authentication processing. The appropriate AAA servercommunicates with the NAS server and a remote server (that storescontent) to process the requests. The server 111 can utilize a varietyof authentication methods, such as Password Authentication Protocol(PAP), challenge-Handshake Authentication Protocol (CHAP), andExtensible Authentication Protocol (EAP). Additionally, among otheraccounting features, the server 111 can generate call detail records(CDR) based on accounting start and stop RADIUS messages from the NASserver. During establishment of a communication session, the NASnotifies the AAA server 111 that a successful session has beenestablished through the use of an Accounting-Request message to startthe session. The Accounting-Request message specifies the type ofservice that is being delivered. The session is terminated when theclient sends an Accounting-Request message to stop the session. Theexchange of these messages can serve as a trigger to determine a“complete” session for the purposes of tracking the frequency of thesessions. RADIUS and the NAS are more fully described in InternetEngineering Task Force (IETF) Request For Comment (RFC) 2865 entitled“Remote Authentication Dial In User Service (RADIUS)” (June 2000), andRFC 2881, entitled “Network Access Server Requirements Next Generation(NASREQNG) NAS Model” (July 2000); both of which are incorporated hereinby reference in their entireties.

In support of fraud monitoring, the fraud detection system 101 supportsa number of functions. The system 101 provides an interface withexternal systems; for example, to receive information on monitoredactivities (e.g., billed connection and failed authentication events)through, for instance, a once-a-day (or more frequently, depending onthe application) flat file transfer. The system 101 detects and analyzessuspected fraud by applying various detection techniques to user sessionevents, and generating alarms when suspicious patterns are detected. Thefraud detection system 101 provides case management by correlatingalarms into cases and prioritizing them for analysis; the resultantinformation can be output to a Graphical User Interface (GUI) in form ofCase Summary and Case Detail screens.

To appreciate the advantages of the fraud detection system 101,according to the present invention, it is instructive to understand thechallenges associated with fraud detection in the context of datacommunication services, as opposed to traditional telephony services.

Whereas telephony fraud detection is mostly concerned with completedcalls and the duration of such calls, dial-up services exhibit othercharacteristics requiring greater analysis. For example, in telephony aseries of calls to non-working numbers is usually innocuous, whereas indial-up services a series of failed log-in attempts, particularlyinvolving a progression or sequence of attempted user IDs or passwords,can indicate a purposeful hacking attempt. In data calls, such asdial-up call services, factors like log-in frequency, geographicdiversity, and simultaneity of usage are meaningful in effective frauddetection, and hence, is profiled on a “per usage account” basis toaccurately distinguish fraudulent patterns from normal use.

A “usage account” refers to any arrangement among an entity and aservice provider. As used herein, the term “usage account” may refer toan arrangement involving a single user or a large group of users such asa business enterprise wherein the usage by all users is accounted forcollectively. Thus, where data is collected for a given user ID or forall use by a given business enterprise, the term “usage account” appliesto both. Both individual users and groups of users may exhibitcharacteristic patterns of usage. Unexpected or unexplained changes inusage patterns for a given usage account, whether consideredindividually or across a population of users in an enterprise, mayindicate fraud activity. Adding to the challenge of fraud prevention isthe fact that some individual usage accounts are intended to be sharedby individuals—and others are not. Without stored usage profileinformation, it is not apparent to the analyst whether the usage accountshould be shared.

Data relating to sessions and unsuccessful logon events may beaccumulated, analyzed and reported in terms of several differentcategorizations. It is possible to assemble information pertaining to agiven host or domain to provide a view of log-in and usage across allUser IDs, for example. It may be desirable to also monitor use of aspecific host/user ID. On a more global scale, statistics may becollected and analyzed based on originating country, meaning across allactivity and host/user IDs involving that country. Similarly, it may beuseful to classify information by a particular partner network to lookfor patterns at that level.

With respect to dial-up access services, patterns of normal usage mayvary widely from one account to another. Some businesses, such as anationwide delivery service, may employ a large number of mobile devicesthat record deliveries, dispatching and other transactions.Communications for such accounts may comprise a large number of shortduration (possibly 30 seconds or less) communications sessions each day.Due to a variety of conditions, it is also possible that many of thelog-on attempts by the mobile devices may initially fail. This patternof high usage and high log-in failure may be deemed perfectly normal forthis type of account. In fact, in accordance with an aspect of thepresent invention, the ratio of bad logon attempts to successfulattempts is a meaningful index of behavior for a given account.

In other cases, a given account may maintain a constant communicationssession by which a remote device may send telemetry information to ahost system. The session may remain continually active, 24 hours-a-dayfor months or years at a time. While it may seem pointless to monitorsuch usage, there is always the possibility that a fraudulent party maydetermine how to use the same account to conduct other sessions. It isdesirable then to monitor for multiple simultaneous log-ins,geographically diverse usage, and usage per day exceeding 24 hours. Itis important not to let the prolonged connection times, which areactually normal for this type of account, to “mask” other, perhaps moresubtle, abnormal behavior. The system 101 can receive “intermediate”session duration records. In other words, if the user never hangs up, aduration record is never collected and sent to the system 101. Toaddress this, a “session-in-progress” record can be transmittedperiodically (e.g., every hour) to indicate that a session has beeninitiated and it is still active.

As evident from the above discussion, fraud in the context of dial-upservices presents a unique challenge over traditional telephonyservices. According to an embodiment of the present invention, the frauddetection system 101 addresses the above challenges by accounting forthe following factors in its analysis of fraudulent use: hostnames/domain names, country blocking, terminating class, originatingAutomatic Number Identification (ANI), number of originating countries,and failure codes. It is noted that other factors (e.g., communicationsession durations, number of failed attempts, etc.) can be utilized aswell, depending on the particular profile desired.

An entirely different facet to fraud monitoring of data calls (e.g.,dial-up services) relates to unsuccessful log-in attempts. A highincidence of failed log-in attempts can, in some cases, indicateattempted “hacking” or other forms of abuse. In particular, a fraudperpetrator may obtain a user ID and set about guessing passwords or maytry to guess a host name. Often, the attempt to hack a host name isevidenced by incorrect host names that are similar to the actual name.For example, a series of attempted logons using invalid host names like“ACMEnews” may be an attempt to guess a valid name such as“ACMENewsCorp.” Occasionally, the invalid attempts appear to beconverging on a desired hacking target. Such attempts can serve toindicate a problem with the authentication system—for example, thesystem currently is not accepting legitimate user IDs and passwords.

One pattern that often occurs when access to communications service hasbeen stolen is rapid, often exponential, acceleration in usage. A fraudperpetrator may obtain a user ID and password to get onto a service andthen may sell or distribute the user ID/password for use by others. Asthe access information is passed to a growing chain of illegitimateusers, the incidence of logons and simultaneous logons escalatesquickly. With a fraud monitoring system 101 reviewing account activityon a frequent basis, this type of usage acceleration can readily bedetected as this behavior is almost always atypical for an established,legitimate account. Early detection of the fraud and disabling of thecompromised user ID and password can limit the damage and is far morepreferable to the customer than unexpectedly receiving a multi-milliondollar invoice when their normal bills have historically been in thethousands.

As in the field of controlling fraud losses in telephone networks, oneapproach for curtailing losses due to dial-up communications fraud is toidentify countries exhibiting a high incidence of fraudulent activityand to simply block communications attempts from those countries.Unfortunately, blocking a given country sacrifices legitimate trafficand business opportunities and is actually ineffective in protectingagainst fraud. Whenever one country is blocked, skilled fraudstersquickly find ways to circumvent such measures by, for example, routingcommunications through other countries.

However, in accordance with an exemplary embodiment, the system 101provides for an overview of network activity that allows for correlationof fraudulent activity, even as it changes location and exhibitsadaptation to thwart countermeasures. Following a blocking maneuver, thedisplaced fraudulent traffic may eventually re-appear from anothercountry and may be readily targeted for analysis. In accordance with anexemplary embodiment, the system 101 monitors remote access activity(e.g., dial-up) and can serve as, or be coupled to, a differentmonitoring system that monitors telephony activity so that correlationmay be achieved. This can improve the ability to detect abuse in atimely manner even as locations are changed.

The brute force approach to blocking entire countries also complicatesthe business arrangements made with some accounts. In some instances, anaccount holder desires to communicate with a given country despite theservice provider's adverse experiences with that country. Often, awaiver must be negotiated such that the service provider makes anexception to policy and the account holder assumes responsibility forsuch use, including fraudulent abuse if it does occur.

In accordance with an exemplary embodiment of the present invention,so-called “terminal class” information is collected in order todetermine what type of call was used to reach the host. For example, itis sometimes noteworthy when a toll-free 800 (or long distance access)number is used to reach a host, and is suspicious when the call from aremote log-on location would normally have been a local call anyway.

In addition to mechanisms for detecting anomalous events, or patternsspanning many events, there is a need to bring suspicious activitypatterns to the attention of analysts who can review the circumstancesand act upon the information provided by the fraud detection system 101.In particular, it is important to prioritize the information so thatfraud activities having the highest potential impact (monetarily or interms of network security) are brought to the forefront of the analyst'sworking queue. For this reason, some exemplary embodiments of thepresent invention provide for comparative multiplier factors derivedfrom statistics gathered for various originating countries and forvarious partner networks. These multiplier values are applied to a rawseverity score derived for each “case.” This has the effect of furtherpromoting some cases that relate to historically fraud-ridden sourcesand which have a higher likelihood of representing fraudulent activityor carry a higher impact of such activity.

Another useful category by which to collect data is the originatingtelephone number or Automatic Number Identification (ANI). Thisinformation can be used to pinpoint the source of attacks even againstmultiple hosts. Preventive action may then be taken, perhaps immediatelyduring abuse, against perpetrators who would otherwise be difficult todetect and control. In accordance with an embodiment of the presentinvention, originating ANI information is collected and used so thatevents, even ones involving different hosts and different systems oraccounts, may be correlated. This aspect lends a powerful degree ofcontrol over the behavior of a localized source of fraudulentactivity—more so than would be possible by examining only eventsinvolving a single host.

Detection of fraud in relation to dial-up services may employ a similarprocessing infrastructure to that used in detecting fraud in a telephonynetwork. One such fraud analysis system is depicted in commonly assignedU.S. Pat. No. 6,208,720 to Curtis et al., which is hereby incorporatedby reference in its entirety. However, the parameters that may bemonitored and the types of patterns that must be discerned to detectpossible fraud are quite different from, and more complex than, those intraditional telephony. The present invention advantageously adapts suchan infrastructure to detecting abuses of remote access services.

Yet another aspect that may be monitored in accordance with the presentteachings is the number of countries from which originations occurwithin a given time period, such as a within a 24-hour period. Manyaccounts will tend to exhibit a low number or at least a fixed number inthis regard. Similar to a sudden shift in specific countries, a suddenincrease in the number countries may elevate a pattern of activity suchthat it warrants review by a fraud analyst. It is noted that inaccordance with the techniques provided herein and in conjunction withU.S. Pat. No. 6,208,720 to Curtis et al., several “mild” pattern shiftsmay be correlated to escalate the priority of a given pattern within theattention of fraud analysts.

As dial-up attempts are made, a variety of events are reported to afraud detection system 101 in accordance with an embodiment of thepresent invention. Failed attempts have particular significance in thecontext of dial-up access. Dial-up attempts may fail for a number ofreasons. For example, from time to time, a “kill code” associated with afailed attempt will indicate “host not accessible” or “bad connection.”These occurrences are generally rare and discounted as being randomproblems due to congestion or poor telephone connections.

In contrast, a “kill code” specifying “bad user ID or password” mayindicate that the attempt was one of many similar failed attemptsresulting from someone attempting to hack a dial-up resource. Indeedcorrelation with other such events and analysis of the particular host,user ID, and password used will help distinguish hacking from innocentcauses of isolated failures, such as simple human error or poorconnection quality. Another possible kill code relates to a “bad hostname.” These occurrences are of particular interest because, asmentioned earlier, a hacker may try to guess a host name and a fraudanalyst may be able to detect a pattern among attempts. An analyst maybe able to predict what host the hacker is targeting.

As explained above, usage patterns can vary from one account to another;what is typical or normal behavior on one account (or domain) may beanomalous and problematic on a different account. Accordingly, the frauddetection system 101 characterizes normal patterns of activity on aper-account basis or at least categorizes accounts into behavior groups,as described in FIGS. 2 and 3. To support fraud monitoring of dial-upservices, abusive use of a dial-up connection can be characterized by,but are not limited to, the following attributes: large number of failedlog-in attempts, extremely long duration, intercontinental or otherwisecostly communications, communications involving certain countriesexhibiting high fraud, or large numbers of geographically scattered orsimultaneous sessions for a given account. However, such attributes arenot dispositve of misuse. Certainly, fraudulent patterns exhibiting oneor more of these key characteristics are observed in practice. However,a significant amount of legitimate usage also exhibits one or more ofthese characteristics, complicating the detection of fraudulent usage.It is thus recognized that a more tailored approach is needed toeffectively monitor for fraud in data communication services.

As mentioned, the fraud detection system 101 can map the WAN sessioninformation to an event that is analyzed for fraud detection. As will beexplained later, the system 101 defines the event, according to oneembodiment of the present invention, to be either a billed connectionevent or a failed authentication event. The system 101 can also deriveany additional information or fields required for alarm and casegeneration, wherein cases are assembled based on rules governing theevents. The system 101 further supports provisioning of events to asingle billing method. Both single- and multi-event detection algorithmscan be utilized by the fraud detection system 101, wherein the use ofcustomized thresholds are permitted as well as consolidation of evidenceinto cases (consolidation on HostUserId, HostNetwork, and HostCountry).The fraud detection system 101 can receive data files with HostParameter File (HPF) information (e.g., via Secure SHell (SSH)/SecureCoPy (SCP), File Transfer Protocol (FTP), etc.), if available, andprovides via a GUI display of information on the cases. The GUI canadditionally display host information (including provisioning andblocking set data) and customer notes for each unique Host Name/Accountindex.

The fraud detection system 101 utilizes different categories of rules:Normalization/Enhancement, Provisioning, Detection, Case Consolidation,and Prioritization (e.g., alarm level and case level). The system 101monitors user dial-up “sessions” for users on the WAN 103, which, in anexemplary embodiment, is a packet switched network, such as an IPnetwork or an X.25 network. Two types of events are processed by thesystem 101: Billed Connections that represent partial or completed userdial-up sessions (both start time and duration are recorded), and FailedAuthentications that represent user sessions that were not successfullyauthenticated. In other words, the fraud detection system 101, accordingto one embodiment of the present invention, monitors two types ofconnections: billed connections and failed authentications, and thusreceives the corresponding session record types from the WAN 103.

Table 1 summarizes the fields contained in a billed normalized eventbased on the Billed Connection event. Table 2 summarizes the fieldscontained in a failed normalized event based on the FailedAuthentication event. For purposes of explanation, the normalized eventnames are “BilledConnect” and “FAuth.”

TABLE 1 NORMALIZED SESSION RECORD DEFINITION FIELD NAMES DATA FILE FIELDNAME (Example) billingKey1 BILLING_KEY_1 Display only. billingKey2BILLING_KEY_2 Display only. sessionLoginTime ORIG_LOGIN_TS Time sessionlogin occurred. startTime derived from: Login time for the userORIG_LOGIN_TS session. stopTime derived from: End time of the billingORIG_LOGIN_TS record. CONN_DUR duration CONN_DUR Current elapsed time inseconds that end user was logged in. priorConnectDuration PRIOR_CONN_DURElasped time of the user's previously reported connection..totalConnectDuration derived from: For long sessions in CONN_DURprogress, the total duration PRIOR_CONN_DUR added to prior cumulativeduration sessionInProgress Derived from: Previously reported elapsedPRIOR_CONN_DUR time in seconds that end user was logged in termClassTERM_CLASS_CD Code for access method. Display only userNodeNameUSER_NODE_NAME Node name that the user utilized to establish connection.Display only. (FOM) userPortNumber USER_PORT_NBR Port number on accessnode used. Display only. partnerNetwork GATE_NETWK_ID Identification ofPartner Network. origLocationClass BILL_CLASS_CD Code for originatinglocation. Display only. baudRate BAUD_RATE_CD Data transmission rate.Display only. destLocationClass BILL_CLASS_CD2 Code for destinationlocation. Display only. rateCode BILL_EVENT_CD Point-to-point billingsurcharge code. Display only. timeZone TIME_ZONE_CD Geographical regionof end user. host GROUP_CD Identification of host that was accessed.CallingAddress ADDR_STG Originating network address of the user session.Display only. userId ENTRY_NETWK_USER_ID End user who accessed thenetwork. batchId BATCH_ID Identifies the unique collection of usagerecords. Display only. bytesReceived CHAR_RECV_CNT Input data volumesent to user. Display only. bytesTransmitted CHAR_TRANSM_CNT Input datavolume sent from user. Display only. tgaIPAddress TGA_IP_ADDR_STG IPAddress for Telnet Gateway Application. Display only. tgaSourcePortTGA_SOURCE_PORT Display only. tgaDestPort TGA_DEST_PORT Display only.userIPAddress USER_IP_ADDR_STG IP address assigned by WAN to the enduser. Display only. hanId HAN_ID Identification of the Host AdjacentNode user was connected to. Display only. freeFlag FREE_FG Flag toidentify if usage is billable to end user. Display only. cisFlag CIS_FGFlag to identify CompuServe Information Customer. Display only. pppFlagPPP_FG Flag to identify if point-to- point protocol used. Display only.outboundChargeFlag OUTBD_RVRS_CHRG Flag to identify if outbound call wascollect or prepaid. Display only. excessUserFlag EXCESS_USER_FG Displayonly. billDate BILL_DATE Date data entered collection system. Displayonly. recordLayout derived Original record type. (e.g., Billed_Instance)billingMethod derived Network billing type. origCountryCode To besupplied Country from where user originated call in ISO format.origCountryName derived from: Country name derived from origCountryCodeorigCountryCode. group derived Fraud Detection system group. hostUserIdderived Key used for alarm generation and case consolidation.hostOrigCountry derived Key used for alarm generation and caseconsolidation. hostPartnerNw derived Key used for alarm generation andcase consolidation.

TABLE 2 NORMALIZED SESSION RECORD DEFINITION FIELD NAMES DATA FILE FIELDNAME (EXAMPLE) partnerNetwork GATE_NETWORK_ID Identification of PartnerNetwork. sourceIPAddress SOURCE_IP_ADDRESS IP address of the machinethat generated the record. Display only. sessionLoginTime TIMESTAMP Timesession login attempt occurred. startTime derived from: Time sessionlogin attempt TIMESTAMP occurred. killCode KILL_CODE Code identifyingwhy login was denied. Display only. reasonCode REASON_CODE Codeidentifying why call was denied. Display only. CallingAddressCALLING_ADDRESS Network address for the user's session. CalledAddressCALLED_ADDRESS Network address user attempted to connect to.gatewayInteractionNo GATEWAY_INTERACTION_NO Unique session numberassigned by parter network. Display only. host HOST_NAME Identificationof host that user attempted to access. userId NETWORK_USER_ID User IDused for attempted access to network. userNodeName NODE_NAME Node namethat the user utilized to establish connection. Display only.userPortNumber PORT_NUMBER Port number on access node used. Displayonly. CallId CALL_ID Display only. Flags FLAGS Display only.transitNwId1 TNIC_1 First transit network identifier code. Display only.transitNwId2 TNIC_2 Second transit network identifier code. Displayonly. transitNwId3 TNIC_3 Third transit network identifier code. Displayonly. transitNwId4 TNIC_4 Fourth transit network identifier code.Display only. batchId BATCHID Identifies the unique collection of usagerecords. Display only. billDate BILL_DATE Date data entered collectionsystem. Display only. tgaIPAddress TGA_IP_ADDR_STG IP Address for TelnetGateway Application. Display only. tgaSourcePort TGA_SOURCE_PORT Displayonly. tgaDestPort TGA_DEST_PORT Display only. recordLayout derivedOriginal record type. (e.g., Failed_Instance) billingMethod derivedNetwork billing type. origCountryCode To be supplied Country from whereuser originated call. origCountryName derived from: Country name derivedfrom origCountryCode origCountryCode. group derived Fraud detectionsystem group. hostUserId derived Key used for alarm generation and caseconsolidation.

The fraud detection rules used for alarm generation are shown in thetable below. The actual threshold values can be updated throughuser-maintained alarm tables via the GUI. Table 3 summarizes theexemplary detection rules for generating single-event and multi-eventalarms:

TABLE 3 DETECTION RULE (SHORT NAME) ALARM TYPE THRESHOLD SOURCE LongDuration (LDur) Single-event Default Custom hostUserId Custom hostAccumulated Duration - User Multi-event Default ID (ADurUser) CustomhostUserId Custom host Accumulated Duration - Multi-event DefaultCountry (ADurCtry) Custom hostOrigCountry Custom origCountryNameAccumulated Duration - Multi-event Default Network (ADurNw) CustomhostPartnerNw Custom partnerNetwork Hot Originating Country (HOC)Single-event N/A Failed Authentication (FAuth) Multi-event DefaultCustom hostUserId Custom host Simultaneous Session (SS) Multi-eventDefault Custom hostUserId Custom host Accumulated Duration - Multi-eventCustom Country Terminal Class hostOrigCountry/termClass/service(ADurCtryTC) Type combination Completed Connection Multi-event DefaultFrequency (CCF) Custom hostUserId/termReason Custom host/termReason

The fraud detection processes employing these rules are explained withrespect to FIGS. 4-10. Such rules result in the generation of variousalarms. Table 4 enumerates exemplary alarm level fields.

TABLE 4 ALARM FIELD NAME TYPE DESCRIPTION creationTime All Contains theDate and Time the Alarm was created duration LDur Contains the totalduration of the events associated with the ADurUser alarm. ADurCtryADurNw ADurCtryTC CCF fAuthCount FAuth The number of failedauthorization events in the alarm. modificationTime All Contains thedate/time alarm was last updated. name All Contains the Alarm violation(LDur, ADurUser). Also known as alert type or evidence type. numEventsAll Indicates the number of events contained in the alarm. priority AllContains the alarm priority. processingState All Indicates theprocessing state of each evidence (for example, New, Processed, Updated,Excluded) threshold LDur, Indicates the threshold value met or exceeded.ADurUser ADurCtry ADurNw FAuth SS ADurCtryTC threshold_source LDur, Typeof threshold applied (i.e., Custom-HostUserId). ADurUser ADurCtry ADurNwFAuth SS ADurCtryTC CCF host LDur Used in alarm exemption. ADurUser HOCFAuth CCF origCountryCode ADurCtry Used in alarm exemption.partnerNetwork ADurNw Used in alarm exemption. hostUserId LDur Used forcase consolidation. Not displayed with alarm ADurUser information. HOCFAuth SS hostOrigCountry LDur Used for case consolidation. Not displayedwith alarm ADurCtry information. HOC ADurCtryTC CCF hostPartnerNw LDurUsed for case consolidation. Not displayed with alarm ADurNwinformation. HOC DurThreshold LDur, Indicates the duration thresholdvalue met or exceeded. ADurUser Exported. Not displayed. ADurCtry AdurNwADurCtryTC CountThreshold ADurUser Indicates the count threshold valuemet or exceeded. ADurCtry Exported. Not displayed. AdurNw AdurCtryTC SSFauth CCF

The fraud detection system 101 can consolidate the alarms into casesthrough the use of case-level fields for case filtering, prioritization,and query. That is, the system 101 performs alarm correlation using theconcept of a case, which is an encapsulation of related alarms andassociated session records into a data set based upon a particular alarmrecord search-key (i.e., a correlation key field). The case is thengiven an ID (caseID), which is used throughout subsequent correlation,prioritization, user display, and reporting processes (if applicable).

The cases can be organized by types, for example, based on a hostUserID, host country, or host network. The Case Type HostUserIdconsolidates applicable alarms by the hostUserId field. These casescontain all alarms where a specific userId was used to log into aspecific host. The following alarm types are consolidated in theHostUserId cases: LDur, ADurUser, HOC, CCF, SS, and FAuth. With regardto the host country, such a case type consolidates alarms by thehostOrigCountry field, whereby these cases contain all alarms where aspecific originating country was used for access to a specific host,regardless of the UserId. The following alarm types are consolidated inthe HostCountry cases: ADurCtry, and ADurCtryTC.

For presentation, the fraud detection system 101 defines case-levelfields made available for presentation (e.g., via Case Summary and CaseDetail screens), per Table 5.

TABLE 5 FIELD NAME DESCRIPTION billingMethods The network billing typesincluded in the case. caseId The unique case key value (either aHostUserId, HostCountry, or HostNetwork value). caseType For example,HostUserId, HostCountry, or HostNetwork creationTime Indicates the dateand time the case was created duration The sum of the duration of eachbilled sessions in the case. This field is recalculated each time analert is updated or added to the case. evidenceTypes This field containsa list of all unique evidence types in the case. lockedBy Indicates theuser ID that has the case locked. modificationTime Indicates the Dateand Time a Case was last updated. priority Indicates the score of thecase. This field is recalculated each time an alarm is updated, added,or excluded in a case. ruling Indicates the last ruling made on a case.Valid rulings can be Fraud, Not Fraud, and Pend. The default Ruling isblank. host The 6-character host name associated with the case.Contained within the caseId. accountNumber The customer account to whichthe host belongs. Can be obtained via table lookup using the host as thekey. accountName The customer account name associated withaccountNumber. Can be obtained via table lookup using the host as thekey. accountIndex The account index associated with the account. Can beobtained via table lookup using the host as the key. origCountryNamesIndicates the unique originating country names that are contained in theevents of the case. origNetworkIds Indicates the unique partner networksthat are contained in the events of the case. status Indicates thestatus of the Case: Open or Closed. displayable Set by implementation:TRUE or FALSE.

The fraud detection system 101 supports a variety of reportingfunctions, such as the capability to inquire case information. Forinstance, case queries can be based on the following case level fields:caseType, evidenceTypes, accountNumber, origCountryNames, origNetworks,caseId, and accountName. In addition: basic queries such as Cases LastWorked By Me, Cases Being Worked, Cases By Ruling queries are supported.

Upon analyzing the cases, the fraud detection system 101 generates caserulings on the respective cases. In an exemplary embodiment, the caserulings include Fraud, Not Fraud, Pending, and Referred. Such rulings(or status information) can be made available to the users. The alarmswithin a case can be active or inactive (also referred to as excludedalarms). When an alarm is first added to a case, it is active. If a userrules a case as “Fraud” or “Not Fraud,” all alarms in the case at thattime are changed to inactive (excluded) and remain inactive for the lifespan of the case. Active alarms contribute to the case priority and areused when calculating various case attributes, such as the totalduration of alarms in a case. When the case has a most recent ruling of“Pending”or “Referred,” the case is prioritized in the same manner as acase without a ruling, and then can be redisplayed, when a new alarm isadded to the case.

The fraud detection system 101 utilizes rules for alarm and caseprioritization. Each alarm type can be assigned an initial priorityassociated with a configurable value. The alarm types can include LDur(Long Duration) alarms, HOC (Hot Originating Country) alarms, ADurUser(Accumulated Duration-User), ADurCty (Accumulated Duration-Country),ADurNw (Accumulated Duration-Network), FAuth (Failed Authentication)alarms, SS (Simultaneous Sessions) alarms, and ADurCtryTC (AccumlatedDuration Country Terminal Class). Also, Table 6 lists exemplary caseprioritization rules:

TABLE 6 LEVEL DESCRIPTION CA-1 The case priority are the sum of theactive alarm priorities in the case CA-2 For each unique partner networkin the case that is found in the PartnerNetworkMultiplier table,multiply case score by value found in table CA-3 For each uniqueoriginating country in the case that is found in theOrigCountryMultiplier table, multiply case score by value found in table

As shown in FIG. 1B, the fraud detection system 101 comprises a numberof components, which for the purposes of illustration have labels thatare figurative in nature; the functional analogy is that of the “legal”process, where data is fed into the Witness, such as Device 153, 155 andLaws 157, and processed by the analogy processes, which include aDispatcher 159, Cop/Detective (Single Event and Multi Event) 161, 163,165, DA Office 167, CC Office 169, 171, and Prosecutor 173, 175, anddisplayed on the Graphical User Interface (GUI). Notably, the frauddetection system 101 includes the following rules and components:Witness (Device and Rules) 153, 155, 157, Dispatcher 159, Single EventCop and Single Event Detective 161, Multi Event Cop and Multi EventDetective 165, 167, Assistant District Attorney, District Attorney,Assistant Court Clerk, Court Clerk, Prosecutor, GUI (PC-based),NodeManager/GFSManager, Cleanup Manager, and Tools and Services (CleanupManager, CountDumper, Network Management Interface (NMI), SummaryLogServer, Count Server, Lock Data Files). The functions of theseprocesses and components are detailed below.

According to an embodiment of the present invention, the Witness Devices153, 155 and Witness processes 157 have responsibility for datacollection and are separate processes for Billed Connection and FailedAuthentication events. This approach advantageously ensures that aninterface change to one of the record layouts does not impact theWitness Device 153, 155 and Witness rules code for the other recordtype. Also, this allows each Witness Device 153, 155 to be developed inparallel. The operation of the Witness processes are later described.

The Dispatcher rules are written, for example in C Language IntegratedProduction System (CLIPS), and perform the following tasks on each eventpassed to it by the Witness: record dropping (dropping the event if itmeets certain criteria), group assignment, event enhancement(transiently), rule set assignment, and cop provisioning andpartitioning.

The Single Event Cop (SEC) component is written in CLIPS and createsfeature vectors for the following evidence types: Long Duration (LDur),and Hot Originating Country (HOC). Customized hostUserId, host, anddefault thresholds can be applied to the LDur evidence. After comparingfeature vector information received from the SEC to the applicablethreshold, a Single Event Detective creates the evidence, whenappropriate, and assigns the base priority for each evidence type.

The Multi Event Cop, in an exemplary embodiment, creates feature vectorsfor the following evidence types: Accumulated Duration-User Id(ADurUser), Accumulated Duration-Country (ADurCtry), AccumulatedDuration-Network (ADurNw), Completed Connection Frequency (CCF), andFailed Authentication (FAuth). Customized and default thresholds can beapplied to each of these evidence type; such thresholds can be enforcedthrough the GUI. After comparing feature vector information receivedfrom the MEC to the applicable threshold, a Multi Event Detectivecreates the evidence, when appropriate, and assigns the base priorityfor the evidence type.

The Assistant District Attorney (AsstDA) enhances events and evidencepersistently and can adjust the evidence priorities based upon therules. The District Attorney (DA) adds the evidence to a case. TheAssistant Court Clerk (AsstCC) enhances the case by creating the caselevel fields that are needed by the Court Clerk for case prioritization,based upon the appropriate rules. The Court Clerk (CC) adjusts the casepriority based upon the rules.

The GUI displays cases to the user/analyst so that appropriate fraudmonitoring and response can be performed. By way of example, in astandard Microsoft Windows format (based upon Visual Basic) orweb-based, the GUI provides the user with a Case Summary Screen, with alist of cases arranged in the highest priority order, and a Case DetailScreen providing the details of an individual case. In addition, the GUIsupplies a Table Editors screen for allowing privileged users to changethresholds, reference values, etc., as well as an Account Editors screenfor adding, deleting, and modifying user accounts. Further, a CustomerNotes screen is supported by the GUI to allow users with the capabilityto add, delete, and modify notes pertaining to individual customeraccounts, and to display specific host information (this information canbe persistent; not stored with a specific case).

A script imports HPF (host) data into a database table for use by theGUI. Case, alarm, and event data are viewed by fraud monitoring agentsthrough a workstation GUI. Reporting data can be exported to flat filesfor future use in a reporting database.

Per FIG. 1B, the WAN 103 stores information relevant to the detection offraudulent usage of data communication services within the databases105, 107, which for the purposes of explanation, is denoted as a singleWAN database 151. The billed and failed events are supplied torespective Witness devices 153, 155. The Witness devices 153, 155forward the received data files to the appropriate Witnesses 157. Withthe ability of the fraud detection system 101 to launch more than oneinstance of a Witness 157, each Witness 157 is configurable as to whichfiles it will process. Several instances of the Witness 157 can executesimultaneously.

The Witness 157 can be configured to process certain directory files sothat each Witness processes 157 its assigned data without contendingwith other instances for the same data. According to one embodiment ofthe present invention, two Witnesses 157 (and associated Witness Devices153, 155) are utilized: one to process the BilledConnect data files, andone to process the FAuth data files, corresponding respectively to theBilled Connections and Failed Authentications events. The two Witnessinstances (“BILLED_Instance” and “FAILED_Instance”) 153, 155 performfile processing, filtering, and normalized event generation. For eachWitness, the following Witness sub-components can be developed: WitnessPreprocessor, Witness Device 153, 155, and Witness 157. The WitnessPreprocessor ensures the proper transfer and storage of the data filesfor processing. The Witness Device 153, 155 handles the parsing out ofindividual event records within the .dat files, converts them to thecorrect data types, and writes them to a buffer for the Witness 157 toprocess. The Witness 157 handles the normalization of data records intonormalized events recognized by the fraud detection system 101.

The details of the processing of the Billed Connections and FailedAuthentications events are described in terms of the input and outputdata. By the end of the Witness rules processing, the data will havebeen placed into the events database in the normalized “BilledConnect”and “FAuth” events.

In interface agreements with the WAN group, as mentioned, the .dat filescontaining the BilledConnect and FAuth records are sent, for example,via file transfer by the WAN group into a “/Data/BilledConnect”directory on the fraud detection system server (not shown); therefore,it will not be necessary to write a Witness Preprocessor. Whentransferring files to the fraud detection system server, the WAN groupcan be requested to ensure the correct filenames are used, and thatfiles are completely transferred before the correct filenames are used(to keep the Witness Device from trying to process an incomplete file).

Each Witness Device 153, 155 first starts processing the data (.dat)files that are collected by the fraud detection system 101 and stored inthe predetermined directory (/Data). The following steps are taken oncea file has been selected to process (although not necessarily in thisorder). The file name is changed so that other instance of a WitnessDevice does not attempt to process the file. The Witness Device parsesthe file into individual event records, and applies a filter to dropinvalid entries (for example, not enough fields or record does not matchthe format). For instance, the Witness Device, for BilledConnect, droprecords where host (GROUP_CD) is blank. For FAuth, records where host(HOST_NAME) is blank are dropped. Additionally, the Witness Devicecreates a message packet with header (record count, layout), as well asthe appropriate records, sending them to the appropriate Witness process(read into buffer). The processed filed is then moved to a differentpart of the directory; e.g., “processed” or “invalid” directory.Thereafter, counters are updated for reporting purposes. As noted,periodic polling is performed to check whether there are more files toprocess.

The BILLED_InstanceFileWitDevice 153 then puts all of the data into abuffer that is sent to the corresponding Witness. The format of the datais shown above. Likewise, the FAILED_InstanceFileWitDevice 155 sends thebuffered data to the appropriate Witness process. Each message packetsent to the Witness contains a header record with the followinginformation (per Table 7, below):

TABLE 7 MESSAGE FIELD DESCRIPTION numRecords Number of records layoutRecord layout = BILLED_Instance (or FAILED_Instance)

The Witness Rules handle the data received from theBILLED_InstanceFileWitDevice 153 and FAILED_InstanceFileWitDevice 155,and the normalization of the records into BilledConnect and FAuthevents, respectively. In one embodiment of the present invention, therules for identifying the input Witness Device 153, 155, the blockheader information for the buffer, and reading in the session records(both billed and failed) are stored in a file (e.g., dasFileHeader.rulesfile).

The functionality of the Dispatcher 159 includes the derivation ofspecific fields, suppression, assigning of the group and rule set,partitioning and provisioning to the cop(s), and setting the originationtime. Dispatcher files can be shared with the AsstDA, and thus, areprefixed with “EventCommon.” Build rules can be used to create theProvisioning rules (assigning events to the appropriate rule sets) andPartitioning rules (setting the correct partition) based on the eventtype—for example, Built-SetBilledConnectRuleSetBilledConnection andBuilt-SetBilledConnectPartition.

Table 8 lists derived fields that derived from the BILLED_Instanceand/or FAILED_Instance events either for further processing in theDispatcher 159 or use by other components:

TABLE 8 FIELD DERIVED FROM startTime both BILLED_Instance andFAILED_Instance events stopTime BILLED_Instance events onlysessionInProgress BILLED_Instance events only billingMethod bothBILLED_Instance and FAILED_Instance events hostUserId bothBILLED_Instance and FAILED_Instance events hostOrigCountryBILLED_Instance events only hostPartnerNw BILLED_Instance events onlytotalConnectDuration BILLED_Instance events only origCountryName bothBILLED_Instance and FAILED_Instance events

The above fields, in an exemplary embodiment, are set using aSetFieldsEvent UDF (User Defined Function). To efficiently set thesefields, and provide for greater “configurability” for futureenhancements, the following CLIPS techniques can be used. Namely, theexistence of facts causes rules to fire, instead of salience. Also,deffacts and build rules are used when possible to specify what eventfields are set and how. Further, Tables and Set lookups are used insteadof “hardcoding” translations of numeric codes to textual descriptions(for example, the origCountryName translation).

Because the date and time of a call is received as strings, instead ofnumber of seconds since an epoch, the startTime needs to be calculatedin the Dispatcher 159. The UDF for CreateDateTime accepts a date/time inthe format “YYYY MM DD HH:MM:SS”. The Dispatcher laws convert thesessionLoginTime format (MM/DD/YY hh:mm) to startTime, which is in theformat required by CreateDateTime. CreateDateTime is passed thedate/time string and the timeZone (which is GMT).

The stopTime is derived in the Dispatcher 159 by taking the startTimeand adding the seconds in the duration field using the AddDate UDF. Thisfield can be used to set Origination Time required by the Infrastructurefor measurements and old event delta processing.

The sessinInProgress field is a flag field that represents whether theevent is a long session in progress (long sessions are billed throughmultiple session records that will not be matched). If thepriorConnectDuration is greater than 0, the Dispatcher 159 will setsessionInProgress to TRUE, otherwise FALSE.

The billingMethod provides a mechanism to associate events to theservice provider network. This field can be used for thresholddetermination.

The hostUserId field can be set in the Dispatcher 159 by concatenating(str-cat) the host with userId, separated by a colon (:); for exampleHOSTNAME:johndoe. Similarly, the hostOrigCountry field can be set in theDispatcher 159 by concatenating (str-cat) the host with origCountryName,separated by a colon (:); for example, HOSTNAME:Japan. Thisconcatentating scheme also applies to the hostOrigNw field, whereby thehost with partnerNetwork are separated by a colon; e.g., HOSTNAME:142.

The totalConnectDuration field is set by adding the duration field (inseconds) to the priorConnectDuration field (also, in seconds). TheorigCountryName is set by performing a table lookup using theCountryCodeTable with the origCountryCode used as the key. This lookupcan be performed by the Dispatcher 159, instead of the GUI because agiven country has multiple country codes and the users would like thesemultiple country codes mapped to a unique country prior to alertgeneration and case consolidation.

Using the SetRuleSet UDF, the event is assigned (provisioned to) one ofthe rule sets listed in Table 9 below.

TABLE 9 COP DETECTION RULESET TYPE ALGORITHMS CONSTRAINTSDefaultBilledConnection SEC LDur All BILLED_Instance events HotOrig canbe assigned to this rule set. MEC ADurUser ADurCtry ADurNwDefaultFAuthentication MEC FAuth All FAILED_Instance events can beassigned to this rule set.

The processing of events can be partitioned among multiple componentsbased on key values in the events. Because the SEC involves singleevents (unlike the MEC), events can be round-robinned between as manySEC processes as necessary. This results in the following partitioningof an event: (1) SEC—BILLED_Instance events (DefaultBilledConnectionruleset) are partitioned to DispatcherEventsSEC1; and (2)MEC—BILLED_Instance events (DefaultBilledConection ruleset) arepartitioned to DispatcherEventsMEC_Billed_(—)0 (through 9). Forinstance, FAILED_Instance events (DefaultFAuthentication ruleset) arepartitioned to DispatcherEventsMEC_Failed_(—)0 (through 9).

Rules can be built to call the SetPartition UDF based on deffacts thatdefine the RuleSet and its partitions. These deffacts can be used tobuild rules upon start up, thus allowing for the addition of newRuleSets and Partitions on the fly. Also, in the case that multiple MECsare needed in the future, a function can be written that takes the lasttwo digits of the key and returns an appropriate partition. Thus, if forperformance reasons multiple MEC cops need to be created, the possiblepartitions (and publish titles) can be configured so that each MEC getscertain events. This permits ease of adding more MECs without having tochange any CLIPS code. If the key is alpha-numeric, it can be necessaryto convert an alpha-numeric character to a 0-9 numeric value.

For events with a recordType of BILLED_Instance, using theSetOriginationTime UDF, the origination time of the event can be set tostopTime. For events with a recordType of FAILED_Instance, using theSetOriginationTime UDF, the origination time of the event can be set tostartTime.

The Single Event Cop (SEC) performs the following functions: subscribesto the normalized events published by the Dispatcher 159, creates one ormore features based on the events received (based on feature vectorproperties), adds the features to a feature vector, and publishes thefeature vector to the Single Event Detective (SED). If the rules forcreating a feature vector are met (based on event type and rule set),the SEC rules will assert a control fact (FeatureVectorInfo). In anexemplary embodiment, one rule can be used for checking the LongDuration threshold, and another rule for checking if a Hot OriginatingCountry exists. If this control fact is asserted, theCreateFeatureVectorRule creates the appropriate feature vector based onfacts that specify which fields to add to the feature vector.

The creation of the feature vector is accomplished using theCreateFeatureVector UDF. Each evidence type uses its own feature vector,e.g., LDur_FV and HOC_FV. To be able to generate evidence, the totalsession duration (totalSessionDuration) can be compared against a LongDuration threshold determined in the SEC as follows. First, there can bea lookup using the LookupTableFeature UDF in the LDThresholds table withthe hostUserId. If the hostUserId is found in the table, “customHostUID”can be placed in the thresholdSource field. If no customized hostUserIdis found, the LDThresholds table is then checked using the host. If thehost is found in the table, “customHost” can be placed in thethresholdSource field. If no customized host is found, the LDThresholdstable is then checked using the Default key, and “Default” is populatedin the thresholdSource field.

The following event features (FVProperties) are set in the featurevector: duration, host, hostOrigCountry, hostPartnerNw, hostUserId,threshold, and thresholdSource.

The origCountryCode can be compared to a predefined list of countrycodes to determine if it is “hot.” The HotOrigCountries set is used, viathe ExistsInSetFeature UDF, to determine if the origCountry is in theset. If the origCountyCode is not set, then the HOC lookup will not beperformed. The following event features (FVProperties) are set in thefeature vector: hostOrigCountry, hostPartnerNw, and hostUserId.

As noted, templates can be utilized for the SEC rules.

The Multiple Event Cop (MEC) subscribes to the normalized eventspublished by the Dispatcher 159, creates the necessary features, createsfeature vectors, and publishes the feature vectors to the MED. Accordingto one embodiment of the present invention, summation rules can becreated for the Billed MEC evidence types, and simple count rules can becreated for the Failed MEC evidence type. The rulesDefineSummationFeatureRule and DefineSimpleCountRule define all featuresthat are summation based or simple count based, respectively. The MECdesign utilizes the (Key {keyName}) fact that is available through theInfrastructure. This fact specifies the key for which the event ispartititioned. For example, the facts (Key HostCountry) (Key HostUserId)and (Key HostNetwork) can be asserted to determine which feature vectortypes can be created for a given event. If the rules for a particularMEC contain rules which take measurements for multiple keys, then theKey fact should be included in the LHS of the rule so that only thoseevents which were partitioned to the particular MEC can be run.

From the BILLED_Instance or FAILED_Instance fact, a feature vector iscreated that contains the appropriate information for the Multi EventDetective. This information is supplied to the Detective for possiblegeneration of one of the MEC alarms. The creation of the feature vectoris accomplished using the CreateFeatureVector UDF. Each evidence typeuses its own feature vector: ADurUser: ADurUser_FV; ADurCtry:ADurCtry_FV; ADurNw: ADurNw_FV; and FAuth: FAuth_FV. The followingfeatures are set in the feature vector: host, hostUserId, duration,threshold, and thresholdSource.

The ADurUser alert can be based on the total accumulated duration withthe same hostUserId. This accumulated duration can be compared against athreshold that can be determined as follows. First, there can be alookup using the LookupTableFeature UDF in the ADurUserThresholds tablewith the hostUserId. If the hostUserId is found in the table,“customHostUID” can be placed in the thresholdSource field. If nocustomized hostUserId is found, the ADurUserThresholds table is thenchecked using the host. If the host is found in the table, “customHost”can be placed in the thresholdSource field. If no customized userId isfound, the ADurUserThresholds table is then checked using the Defaultkey, and “Default” is populated in the thresholdSource field.

If a threshold is found, then a feature vector is defined based on thetype of key. After a feature vector is created, the billed session eventduration can be summed within the measurement by calling theCalcSummationFeature UDF. The ADurUser alert will only have onemeasurement window that can be defined using facts that map the featureto the interval and anchor time. That is, the creation of the featurevector is accomplished using the CreateFeatureVector UDF, themeasurement counter is created using the DefineSummationFeature UDF, andthe counter is updated using the CalcSummationFeature UDF.

The ADurCtry alert can be based on the total accumulated duration withthe same hostOrigCountry. This accumulated duration can be comparedagainst a threshold that can be determined as follows. First, there canbe a lookup using the LookupTableFeature UDF in the ADurCtryThresholdstable with the hostOrigCountry. If the hostOrigCountry is found in thetable, “customHostCtry” can be placed in the thresholdSource field. Ifno customized hostOrigCountry is found, the ADurUserThresholds table isthen checked using the origCountry. If the origCountry is found in thetable, “customOrigCtry” can be placed in the thresholdSource field. Ifno customized origCountry is found, the ADurCtryThresholds table is thenchecked using the Default key, and “Default” is populated in thethresholdSource field.

If a threshold is found, then a feature vector is defined based on thetype of key. After a feature vector is created, the billed session eventduration can be summed within the measurement by calling theCalcSummationFeature UDF. The ADurCtry alert will only have onemeasurement window that can be define using facts that map the featureto the interval and anchor time. The following features are also set inthe feature vector: HostOrigCtry, origCountryCode, threshold,thresholdSource, and duration.

The ADurNw alert can be based on the total accumulated duration with thesame hostPartnerNw. This accumulated duration can be compared against athreshold that can be determined as follows. First, there can be alookup using the LookupTableFeature UDF in the ADurNwThresholds tablewith the hostPartnerNw. If the hostPartnerNw is found in the table,“customHostNW” can be placed in the thresholdSource field. If nocustomized hostPartnerNw is found, the ADurNwThresholds table is thenchecked using the partnerNetwork. If the partnerNetwork is found in thetable, “customNW” can be placed in the thresholdSource field. If nocustomized partnerNetwork is found, the ADurNwThresholds table is thenchecked using the Default key, and “Default” is populated in thethresholdSource field.

As with the ADurCtry alert, if a threshold is found, then a featurevector is defined based on the type of key. The following features areset in the feature vector: HostPartnerNw, partnerNetwork, threshold,thresholdSource, and duration. After a feature vector is created, thebilled session event duration can be summed within the measurement bycalling the CalcSummationFeature UDF. The ADurUser alert will only haveone measurement window that can be define using facts that map thefeature to the interval and anchor time. The creation of the featurevector is accomplished using the CreateFeatureVector UDF, themeasurement counter is created using the DefineSummationFeature UDF, andthe counter is updated using the CalcSummationFeature UDF.

The FAuth alert can be based on the total number of failedauthorizations with the same hostUserId. This count can be comparedagainst a threshold that can be determined as follows. First, there canbe a lookup using the LookupTableFeature UDF in the FAuthThresholdstable with the hostUserId. If the hostUserId is found in the table,“customHostUID” can be placed in the thresholdSource field. If nocustomized hostUserId is found, the FAuthThresholds table is thenchecked using the host. If the host is found in the table, “customHost”can be placed in the thresholdSource field. If no customized host isfound, the FAuthThresholds table is then checked using the Default key,and “Default” is populated in the thresholdSource field.

If a threshold is found, then a feature vector is defined based on thetype of key. The following features are set in the feature vector:hostUserId, host, threshold, thresholdSource, and fAuthCount. After afeature vector is created, the failed session event can be countedwithin the measurement by calling the CalcSimpleCountFeature UDF. TheADurUser alert has one measurement window that can be define using factsthat map the feature to the interval and anchor time. The creation ofthe feature vector is accomplished using the CreateFeatureVector UDF,the measurement counter is created using the DefineSimpleCountFeatureUDF, and the counter is updated using the CalcSimpleCountFeature UDF.

The Single Event Detective (SED) subscribes to the feature vectorspublished by the SEC, creates evidence based on the feature vectorsreceived and the defined detection criteria (BuildRuleEvidenceFacts),and publishes evidence to the DA Office 167. According to an embodimentof the present invention, the single-event evidence types include LDurand HOC. Each of these evidence types apply to BilledConnect event only.Build rules BuildThresholdEvidenceRules and BuildExistsEvidenceRules canbe used to create rules for evidence that are threshold-based (LDur) andfor evidence that is based on whether a feature vector exists (HOC). TheEvidenceProperty Facts will then be used to specify the fields thatshould be added to the evidence.

The following discussion address the evidence that can be created basedupon the feature vector(s) generated by the Single Event Cop. From thefeature vector(s) created by the Single Event Cop, comparisons and valuechecks are made to determine if evidence should be generated. If certaincriteria are met, the UDF CreateEvidence is called, resulting in atransient piece of evidence, along with a pointer to the generatingevent, being created.

The criteria for generating evidence is now described. There is nohierarchy associated with the evidence creation, and an event (featurevector) can generate none or all of the evidence types in its ruleset.When CreateEvidence is called, the appropriate evidence name is given,along with the priority that is read from the configuration file, andthe appropriate partition. Fields are set in the evidence through eitherthe CopyFieldEvidence UDF or the SetFieldEvidence UDF. Build rules canbe used to create the evidence in the SED. There can be correspondingfacts that contain each unique evidence type and the constraint methodthat is used to check if the evidence should be created.

If there is an LDur_FV feature vector, and the duration is greater thanor equal to the threshold, then LDur evidence is created with the UDFCreateEvidence. The LDur evidence contains the following fields:hostUserId (used for case consolidation), hostOrigCountry (used for caseconsolidation), hostPartnerNw (used for case consolidation), host,duration (totalSessionDuration), threshold, and thresholdSource. Also,if there is an HOC FV feature vector, then HOC evidence is created withthe UDF CreateEvidence, with the following fields: hostUserId (used forcase consolidation), hostOrigCountry (used for case consolidation), andhostPartnerNw (used for case consolidation). The initial base priorityfor each evidence type can be set in the SED through either a tablelookup or configuration file entry.

As regard the Multiple Event Detective (MED), a build rule(BuildThresholdEvidenceRules) creates a rule for the creation of each ofthe evidence types; for example, the rule Built-LDurEvidence can becreated. These built rules can be fact-driven and will create evidencewhenever a threshold is met or broken. The appropriate fields can becopied to the evidence from the feature vector.

From the feature vectors created by the Multi Event Cop, comparisons andvalue checks are made to determine whether evidence should be generated.If certain criteria are met, the UDF CreateEvidence is called, resultingin a transient piece of evidence, along with a collection of pointers tothe generating events, being created. The following sections describethe criteria for generating evidence. As with the SED, no hierarchy isassociated with the evidence creation, whereby an event (feature vector)can generate none or all of the evidence types in its ruleset. WhenCreateEvidence is called, the appropriate evidence name is given, alongwith the priority that is read from the InitalAlertPriority table, andthe appropriate partition. Fields are set in the evidence through eitherthe CopyFieldEvidence UDF or the SetFieldEvidence UDF.

If there is an ADurUser_FV feature vector, and the accumulated durationis greater than or equal to the threshold, then ADurUser evidence iscreated with the UDF CreateEvidence. The ADurUser evidence contains thefollowing implementation fields: hostUserId, host, duration (the totalduration of all of the events), threshold, and thresholdSource. The MEDcan set the initial base priority for each evidence type through eithera table lookup or configuration file entry.

If there is an ADurCtry_FV feature vector, and the accumulated durationis greater than or equal to the threshold, then ADurCtry evidence iscreated with the UDF CreateEvidence. The ADurCtry evidence can includethe following fields: hostOrigCountry (used for case consolidation),origCountryCode, duration (the total duration of all of the events),threshold, and thresholdSource.

Additionally, if there is an ADurNw_FV feature vector, and theaccumulated duration is greater than or equal to the threshold, thenADurNw evidence is created with the UDF CreateEvidence, wherein theADurNw evidence specifies the following fields: hostPartnerNw (used forcase consolidation), partnerNetwork, duration (the total duration of allof the events), threshold, and thresholdSource.

For the Failed Authentications (FAuth) event, if there is an FAuth_FVfeature vector, and the number of failed authorizations is greater thanor equal to the threshold, then FAuth evidence is created with the UDFCreateEvidence. The FAuth evidence includes the following fields:hostUserId (used for case consolidation), host, fAuthcount, threshold,and thresholdSource.

Assistant District Attorney (AsstDA) functions include enhancing events,asserting enhanced events, and enhancing evidence. Event enhancementrules (EventEnhancement) are developed for the Dispatcher 159 and sharedwith the AsstDA. The same functions and rules that are used in theDispatcher 159 to set these derived fields are also used by the AsstDA.Thus, the fields (as shown in Table 9) can be persistently added to anevent. It is noted that SetOriginationTime UDF cannot be called from theAsstDA component, and therefore cannot be placed in a file shared by theDispatcher 159 and AsstDA. A file, EventCommonRules can be created forrules shared by the Dispatcher 159 and AsstDA.

The District Attorney (DA) is responsible for adding evidence to thethree DAS case types with the AddEvidenceToCase UDF. Adding evidenceeither results in a new case being generated, or an existing case beingupdated. Using a generic build rule, rules are built at run-time foreach of the different evidence types and their corresponding case types.For example, a Built-AddLDurToHostUserId rule can be created. Based uponthe existence of an evidence fact, a call to AddEvidenceToCase is made.Because the DA is in the DA Office 167, it picks up all of the samerules files (in this case, templates) that the AsstDA is using.

The DAS Assistant Court Clerk (AsstCC) receives case collections fromthe DA Office 167 and enhances the cases with additional case fields.The case-level fields that can be enhanced in the AsstCC are describedbelow. Each case field can be enhanced through a build rule, based onthe specific case type, and record type, if necessary. For example, aValidCaseType fact can be used in a single build rule to create:Built-EnhanceHostUserIdBillingMethod,Built-EnhanceHostCountryBillingMethod, andBuilt-EnhanceHostNetworkBillingMethod. Several of the case fields beloware “list” fields: billingMethods, evidenceTypes, origCountryNames, andorigNetworkIds. For these fields, a rule can be written that adds avalue to the list if is not already on the list (such as,ObtainUnique[fieldName]TypeList). Once the unique list values areobtained, the SetCaseFields UDF can be called.

By way of example, enhancements with respect to each of three DAS casetypes (HostUserId, HostCountry, and HostNetwork) are explained. Thefollowing fields can be added to each case: duration, evidentTypes,accountNumber, accountName, billingMethods, origCountryNames, andorigNetworklds. The duration field of the case is set to the sum of thedurations of all of the case events (using the UDF SumEventField). Thisis the duration field in the event, not the totalSessionDuration. TheevidenceTypes field of the case contains a list of all the uniqueevidence types that are in the case. The accountNumber field of the casecontains an account number obtained by a table lookup from the HostTableusing the host field in any event as the key. The accountName field ofthe case contains an account name obtained by a table lookup from theHost Table using the host field in any event as the key. ThebillingMethods field of the case contains a list of all the uniquebilling methods that are in the events in the case. TheorigCountrieNames field of the case contains a list of all the uniqueoriginating countries (origCountryName) that are contained in the caseevents. The origNetworklds field of the case contains a list of all theunique partner networks (partnerNetwork) that are contained in the caseevents. Networks IDs will remain numeric in this case field. (NetworkIDs can be translated to network names in the GUI).

If a Fraud or Not Fraud ruling is made, the case level fields, duration,evidenceTypes, billingMethods, origCountryNames, and origNetworkIds, canbe reset (for all case types).

The Court Clerk (CC) is responsible for performing the final case scoreadjustments. This is accomplished using the SetCasePriority andMultiplyCasePriority UDFs. Because the Court Clerk is in the CC Office169, 171, it picks up all of the same rules files (including thetemplates) that the AsstCC is using. A build rule can be utilized thatbuilds each of the case multiply rules (CA-2 and CA-3), for each of thethree case types (HostUserId, HostCountry, and HostNetwork). Forexample, a specific built rule can be Built-HostUserIdCA-2. A fact canbe used to match the prioritization rule to the corresponding case-levelfield and lookup table. For the CA-1 multiply rule, the base case scoreis created by summing the individual alert scores. This can beaccomplished in the DA Office 167. With CA-2, the customer is interestedin prioritizing cases according to what networks the sessions originatefrom. The CC will adjust the case score by looking up eachpartnerNetwork from the origNetworklds field in thePartnerNetworkMultiplier table, checking for a valid multiplier value,and then multiplying the case score by the returned value(MultiplyCasePriority UDF). The CA-3 rule involves prioritizing casesaccording to what countries the sessions originate from. The CCaccordingly adjusts the case score by looking up each origCountryNamefrom the origCountryNames field in the OrigCountryMultiplier table,checking for a valid multiplier value, and then multiplying the casescore by the returned value (MultiplyCasePriority UDF).

As earlier described, the Graphical User Interface (GUI) hasresponsibility for displaying the cases, evidence, events, and customerinformation to the user. In addition, the GUI allow users to performmaintenance of user accounts, system tables, and customer information.Further, the GUI can support the following functions: Tool bar—thecurrent buttons on the Case Summary and Case Detail can be replaced withicons on a toolbar, and Table Maintenance. The fraud detection system101 can also utilize icons for the following screens: My Profile, UserAccount Maintenance, Table Maintenance, Threshold Editing, AccountInformation, and Quick Reference Tables.

FIG. 2 is a flowchart of a fraud detection process utilizing a baselineusage pattern for determining fraudulent use, according to an embodimentof the present invention. In step 201, a baseline (or “normal”) usagepattern is established, for example, by analyzing historical data for aparticular account with respect to one or more factors, such as log-infrequency, geographic diversity, simultaneity of use, and duration ofuse. The fraud detection system 101, per the monitor devices, canmonitor the actual usage pattern of the particular account underscrutiny, per step 203. Next, the fraud detection system 101 comparesthe usage pattern with the established baseline usage pattern todetermine whether there is a significant deviation either in view of thetotality factors used to establish the patterns, or one or more factorsthat exceed predetermined thresholds to indicate a high likelihood offraudulent use by the account (steps 205 and 207). This probability canbe based on the number of failed attempts. These factors and associatedthresholding are detailed below in FIGS. 4-9. If the system determinesthat a deviation exists, then the account is designated as a likelycandidate for fraud, as in step 209.

It is possible for activity on an account to shift from a first patternto second pattern. The first pattern may represent legitimate use,whereas the second pattern, though commonly observed as valid use amongother accounts, may represent a departure indicative of fraud.

It is desirable to determine the extent to which user IDs may be sharedand to look for violations involving sharing when there should be none.Some accounts may have a large number of user IDs—enough so that eachuser ID need not be shared among multiple users. If the understandingwith the users in this name space is that user IDs are not to be shared,then it is desirable to detect incidences of sharing as this may beindicative of misappropriation of user IDs and passwords or of othermisbehavior related to fraudulent usage. Aberrant usage may be detectedby determining by overlap in session times, login from a multiplicity ofgeographically diverse locations, and more than 24 hours of use in agiven day (or more than 60 minutes of use in a given hour or real time,etc.).

One mechanism of detection relates to reasonable speeds of physicaltravel and offers a more sophisticated detection than simultaneous use.For example, a log-in from the United States followed by a log-in fromAustralia less than thirty minutes later implies use by more than oneperson because it is presently impossible for the legitimate user totravel that distance along the surface of the earth within the half-hourtime frame. Sufficiently frequent collection and analysis of activitycan provide timely detection of such behavior. It may even be possibleto take immediate action to interrupt communications or otherwiseintervene when abuse can be verified while it is occurring.

Some accounts, especially those having relatively few user IDs, mayallow sharing. Nevertheless, the frequency, duration, and other patternsof use may be useful to monitor for abuse.

Another aspect of accounts relates to geographical distribution. Oneaccount, such as a work-at-home network connection, may be verymonotonous in consistently establishing communications between twoparticular points. An enterprise account may have installationsworldwide and may frequently establish communications among specificcountries and continents. The consistency of the communications in beingfrom a particular set of countries may also vary. A global manufacturermay often communicate among a dozen countries but rarely communicateoutside of this set. A sudden flux of communications involving othercountries could represent fraud or it could represent normal employeetravel or company expansion. Upon detection, it is relatively easy tocheck with the account and determine whether the shift in activity canbe accounted for. It cannot be assumed for all accounts, that such apattern is or is not a fraudulent pattern without considering thebehavior and business needs of the particular account.

For example, it is common for a news agency to dispatch reporters tocover stories in various parts of the world. Reporters uploading data,recorded media and reports will often log-in from locations that are newwith respect to the account and conduct prolonged sessions. It is worthnoting how this same pattern might be clearly indicative of possiblefraud in the context of other account types.

FIG. 3 is a flowchart of a fraud detection process involvingcategorization of usage patterns into behavioral groups, according to anembodiment of the present invention. In an alternative embodiment, thefraud detection system 101 provides for monitoring of the usage pattern,per step 301, and then categorizing such determined usage pattern into abehavioral group among multiple predetermined behavioral groups havingcorresponding reference patterns (step 303). In step 305, theappropriate reference pattern is reference by the fraud detection system101, which then performs a comparison of the monitored usage patternwith the retrieved reference pattern, as in step 307. The frauddetection system 101 next determines whether a deviation exists betweenthe two patterns, per step 309. If a deviation is determined, then theaccount is likely encountering fraudulent use (step 311).

FIG. 4 is a flowchart of a fraud detection process of a single eventexhibiting a long duration, according to an embodiment of the presentinvention. An LDur alarm is generated when the totalSessionDuration fora single billed connection meets or exceeds a default duration thresholdx, defined, for example, in seconds. Additionally, LDur thresholds areallowed to be set by customized hostUserId and host, such thatthresholds can be applied in the following order: hostUserID, host, anddefault.

Per step 401, a duration threshold is set for a single event (i.e.,single activity involving a communication session) according to User ID(identification) and custom host. The duration of the connectionestablished over the WAN 103 is monitored, per step 403. If the durationof the single communication session exceeds a predetermined threshold,as determined by step 405, the fraud detection system 101 generates analert, as in step 407.

FIG. 5 is a flowchart of a fraud detection process using an accumulatedduration associated with a host user identifier (ID), according to anembodiment of the present invention. In this scenario, a durationthreshold is set, per step 501, according to either a host user ID or acustom host. The fraud detection system 101 monitors the billedconnections associated with a single host user ID or a custom host, perstep 503. The durations of the connections are thereafter accumulated,or totaled over a predetermined time interval, t (step 505). The frauddetection system 101, per step 507, determines whether the accumulatedduration exceeds a predetermined threshold, whereby an alert ifgenerated by the fraud detection system 101 if the threshold is exceeded(step 509).

In other words, an ADurUser alarm is generated when the duration of oneor more billed connections on the same hostUserId meets or exceeds adefault threshold for cumulative duration x, over an interval of time t(e.g., defined in seconds). The system 101 supports a configurablesingle definition for ADurUser time t (the interval t will not becustomizable). For example, when one or more billed connections toCorpA:user1 meets or exceeds a duration of 2500 minutes (150,000seconds) for a 24 hour window, an alarm would be generated.Additionally, ADurUser duration thresholds are allowed to be set bycustomized hostUserId or customized host. The duration thresholds,according to an exemplary embodiment, are applied in the followingorder: custom hostUserId, custom host, and default. Also, predefinedhostUserIds or hosts are allowed to be exempted from this alarm type.

FIG. 6 is a flowchart of a fraud detection process using an accumulatedduration associated with a host network, according to an embodiment ofthe present invention. Similar to the process of FIG. 5, a durationthreshold is set, per step 601; however, in this example, the thresholdis based on the host partner network. In step 603, the fraud detectionsystem 101 monitors the billed connections associated with the hostpartner network. The durations of the connections are accumulated over apredetermined time interval, t (step 605). The fraud detection system101, per step 607, determines whether the accumulated duration exceeds apredetermined threshold. If the threshold is exceeded, the frauddetection system 101 generates an alert (step 609).

An ADurNw alarm is generated when the duration of one or more billedconnections on the same hostPartnerNw meets or exceeds a defaultthreshold for cumulative duration x, over an interval of time t (definedin seconds). For example, when one or more billed connections to aparticular host 115 meets or exceeds a duration of 300 minutes (18,000seconds) for a 24 hour window, an alarm is generated. Additionally,ADurNw duration thresholds are allowed to be set by customizedhostPartnerNw or customized network, such thresholds can be applied inthe follow sequence: custom hostPartnerNw, custom partnerNetwork, anddefault. The system 101 can elect to not apply fraud detection tocertain networks.

FIG. 7 is a flowchart of a fraud detection process using an accumulatedduration associated with a host origin country, according to anembodiment of the present invention. In this example, a durationthreshold is set, per step 701, according to a host origin country. Thefraud detection system 101 monitors the billed connections associatedwith the host origin country, per step 703. The durations of theseconnections are totaled over a predetermined time interval, t (step705). The accumulated duration is then compared with a predeterminedthreshold, as in step 707. The fraud detection system 101 generates analert if the threshold is exceeded (step 709). Duration thresholds canbe applied according to the following order; hostOrigCountry,origCountryName, and default.

In other words, an ADurCtry alarm is generated when the duration of oneor more billed connections on the same hostOrigCountry meets or exceedsa threshold for cumulative duration x, over an interval of time t (e.g.,defined in seconds). For example, when one or more billed connections toHostB:Russia meets or exceeds a duration of 1000 minutes (i.e., 60,000seconds) for a 24 hour window, an alarm would be generated.Additionally, ADurCtry duration thresholds are allowed to be set bycustomized hostOrigCountry or customized origCountryName.

Further, the fraud detection system 101 can exempt certainhostOrigCountries or origCountries from this alarm type.

FIG. 8 is a flowchart of a fraud detection process of a single eventassociated with an origin country specified as part of a predeterminedlist of countries having a history of fraudulent activities, accordingto an embodiment of the present invention. A Hot Originating Country(HOC) alarm is generated when a billed session originates(origCountryCode) from country x. Origination x is contained on apredefined list of international country codes. If the origCountryCodeis blank, the HOC should is not applied.

In step 801, a list of host origin countries are specified. In anexemplary embodiment, the countries are enumerated by the country codes.The fraud detection system 101 monitors the origin of the billedsession, as in step 803, and compares this information with the list. Ifthe fraud detection system 101 determines a match, as in step 805, thenan alert is generated (step 807).

FIG. 9 is a flowchart of a fraud detection process based on failedauthentication attempts, according to an embodiment of the presentinvention. In step 901, a threshold value for the number of failedauthentications is set according to a host User ID. Alternatively, thethreshold can be applied in the following order: host User ID, host, anddefault. The fraud detection system 101 then monitors the number offailed authentications of a billed session associated with the host UserID (or the host) over a predetermined interval of time (e.g., 24 hours),per step 903. The fraud detection system 101 then determines whether thethreshold is exceeded based on the monitoring process, as in step 905.An alert (e.g., FAuth alarm) is generated if the threshold is exceeded(step 907).

The fraud detection system 101 of FIG. 1 advantageously providesprofiling on an account-by-account basis. According to variousembodiments, the real-time nature of the data collection and processingof such information enhances the efficiency and accuracy of detectingfraudulent use of data communication services.

FIG. 10 is a flowchart of a fraud detection process using connectionfrequency thresholds, according to an embodiment of the presentinvention. In step 1001, a completed connection frequency, CCF, (orsession count) threshold is set according to one or more selectedattributes. According to one embodiment of the present invention, theseselected attributes, by which a threshold may be set, include theterminating reason, host identifier, host user identifier (e.g., ahostUserID), originating country, partner network (PartnerNW), etc. Thethresholds, in an exemplary embodiment, are set per service type (i.e.,products with different features and different session controls). Forexample, a frequency threshold can be set according to either ahostUserID or a custom host per a specified termination reason attributeand/or specified origination attribute.

The process monitors, as in step 1003, the completed connectionfrequency for, in an exemplary embodiment, a unique log-in string. Thenumber of completed sessions that occur for a given hostUserID within agiven period of time is assessed, per step 1005. A completed session isa connection that has been successfully established and then concluded.According to an embodiment of the present invention, the conclusion of asession can be reported in a variety of ways and attributed to variousdifferent “terminating reasons,” depending on the protocol andtechnologies employed in supporting remote access. A communicationssession can be expressly concluded by formal terminating requests amongcommunicating devices (e.g., hosts 113, 115, 117, 119), as with theissuance of Accounting messages with the RADIUS protocol. When thistermination process occurs, the network access server (NAS) or otherentity through which the connection is made issues a notification, knownas an “accounting stop.” It is recognized that multiple suchnotifications can be created, depending on the particular protocol.

In a dial-up modem connection, when a series of “heartbeats” for theconnection is not received or when, in a WAN connection, no accountingstop is observed after some prolonged period (e.g., nine hours), thesesituations can signify a possible session conclusion. Under thesescenarios, the communication session is assumed to be concluded and canbe reported as having been “autoclosed.” It is noted that severalautoclose indications can be generated for a given session.

It is recognized that in some environments the closure of a connectionmay not be reliably indicated in a timely fashion. According to oneembodiment of the present invention, to more accurately gage the numberof concluded sessions occurring over a period of time, a sliding windowapproach is used for accumulating and analyzing data over a prolongedperiod of time, such as 12 to 24 hours. The approach monitors theparameters over a sliding window (with finer time granularity) of time,as opposed to monitoring over a fixed time interval each day. Observingconnection behavior over a long interval allows some time for somemultiple reports to “settle out” and for the fraud detection system 101to better resolve the apparent conclusion time of a session. Asmentioned above, thresholds for completed connection frequency can beseparately adjusted for “accounting stop” indications versus autocloseindications.

If the number of completed connections satisfies a predeterminedthreshold, then an alert is generated (steps 1007, 1009). For instance,an alert is triggered whenever the number of completed sessionscorresponding to the same user ID (e.g., same login string) for anaccount in a given time period exceeds the connection frequencythreshold value. In other words, a CCF alarm is generated when thenumber of completed connections within, for instance, the samehostUserID meets or exceeds a threshold count x, over an interval oftime t (e.g., defined in seconds). For example, when the number ofbilled connections to CorpA:user1 meets or exceeds a count of 20 for a24 hour window, an alarm would be generated. Additionally, CCF frequencythresholds are allowed to be set by customized hostUserId or customizedhost for a specific termination attribute (e.g., TermReason thatindicates if the session was autoclosed due to no Network-Access-Server(NAS) heartbeat (and therefore could still be active), or actual closeddue to receipt of an official NAS accounting stop). The frequencythresholds, according to an exemplary embodiment, are applied in thefollowing order: custom hostUserId/termReason, custom host/termReason,and default. Also, predefined hostUserIds or hosts are allowed to beexempted from this alarm type.

As evident by the above process, several thresholds can be applied tothe monitored parameters and set at varying degrees of specificity. Avery specific threshold may be set for a particular hostUserID and for agiven termination reason, thereby enabling customized characterizationof a hostUserID in terms of connection frequency and terminatingcharacteristics.

Additionally, a somewhat less specific threshold can be set for a givenhost and terminating reason. This threshold applies to connections tothe host from any hostUserID. Finally, a default threshold can beapplied to generate an alert at a certain completed connectionfrequency; the threshold being equally applicable to any host orhostUserIDs. The time interval over which connections are tracked (orcounted) can be fixed system-wide or customizable at a comparable levelof specificity as the threshold. Moreover, the thresholds can be set asa function of geographic region, such as by originating country.Further, according to one embodiment of the present invention, thethresholds utilized in the processes of FIGS. 4-10 can be assigneddifferent levels of precedence or severity (independent of thespecificity). Under this approach, if a particular threshold of acertain precedence is exceeded or otherwise satisfied, this can triggerthe inclusion of information relating to the threshold in the fraudalert itself. In some installations, fraud analysts may consider somethreshold violations to be of greater significance than others and mayprefer to that certain threshold violations are selectively reported inlieu of others according to some order of precedence. Whereas a givenconnection duration may indeed exceed several thresholds, a precedencemay be established such that one of the threshold violation conditionsis preferentially reported in a fraud alert, the others being viewed assubordinate in importance for fraud analysis purposes. This practicefocuses attention on the most noteworthy threshold violations. Inaccordance with an exemplary embodiment, a precedence order is enabled,determining which of multiple violations is to be included in a fraudalert, by performing threshold comparisons in a particular sequence,such as in order of most specific to least specific. For example, athreshold applicable to a specific host and userID combination will betested before a threshold generally applicable to the host regardless ofuserID. As another example of decreasing specificity, a thresholdapplicable to a particular region in a country will be tested before athreshold applicable to the country “at large”. The total number ofcriteria specified for the threshold is an indication of relativespecificity, as well as the specificity expressed by particular valuesof a criterion. As various thresholds are tested in sequence, the firstthreshold violation encountered triggers a fraud alert based on theviolation and other thresholds need not be tested.

This deliberate sequencing of thresholds comparisons to implement aprecedence order improves processing efficiency by providing an ‘earlyout’ approach during execution. Once a threshold violation of highpriority has been detected, then it is unnecessary to perform furthercomparisons as they will be preempted by the greater precedenceviolation anyway. It should be recognized, however, that othermechanisms may be used to implement an arbitrary precedence order amongthreshold comparisons without departing from the spirit and scope of thepresent invention. Many variations are possible and may have usefulnessin some implementations. For example, precedence of threshold violationsmay be related to relative severity, such as the extent to which thethreshold is exceeded. In some implementations, all thresholds may betested to detect violations even after a significant violation hasalready been detected. Reporting precedence, if any, may be processedafter the thresholds have been checked. In some implementations, it isalso envisioned that a fraud alert may selectively include aspects ofmore than one threshold violation.

It should be generally noted that for every unique combination ofconnection attribute criteria for which a threshold has been set, it maybe useful to maintain a counter that is incremented for each connectionfulfilling the criteria.

The fraud detection processes, as described, advantageously provides amechanism for detecting and curtailing unauthorized use of remote accessconnections.

FIG. 11 illustrates a computer system 1100 upon which an embodimentaccording to the present invention can be implemented. For example, theclient and server processes for supporting fleet and asset managementcan be implemented using the computer system 1100. The computer system1100 includes a bus 1101 or other communication mechanism forcommunicating information and a processor 1103 coupled to the bus 1101for processing information. The computer system 1100 also includes mainmemory 1105, such as a random access memory (RAM) or other dynamicstorage device, coupled to the bus 1101 for storing information andinstructions to be executed by the processor 1103. Main memory 1105 canalso be used for storing temporary variables or other intermediateinformation during execution of instructions by the processor 1103. Thecomputer system 1100 may further include a read only memory (ROM) 1107or other static storage device coupled to the bus 1101 for storingstatic information and instructions for the processor 1103. A storagedevice 1109, such as a magnetic disk or optical disk, is coupled to thebus 1101 for persistently storing information and instructions.

The computer system 1100 may be coupled via the bus 1101 to a display1111, such as a cathode ray tube (CRT), liquid crystal display, activematrix display, or plasma display, for displaying information to acomputer user. An input device 1113, such as a keyboard includingalphanumeric and other keys, is coupled to the bus 1101 forcommunicating information and command selections to the processor 1103.Another type of user input device is a cursor control 1115, such as amouse, a trackball, or cursor direction keys, for communicatingdirection information and command selections to the processor 1103 andfor controlling cursor movement on the display 1111.

According to one embodiment of the invention, the processes of the frauddetection system 101 are performed by the computer system 1100, inresponse to the processor 1103 executing an arrangement of instructionscontained in main memory 1105. Such instructions can be read into mainmemory 1105 from another computer-readable medium, such as the storagedevice 1109. Execution of the arrangement of instructions contained inmain memory 1105 causes the processor 1103 to perform the process stepsdescribed herein. One or more processors in a multi-processingarrangement may also be employed to execute the instructions containedin main memory 1105. In alternative embodiments, hard-wired circuitrymay be used in place of or in combination with software instructions toimplement the embodiment of the present invention. Thus, embodiments ofthe present invention are not limited to any specific combination ofhardware circuitry and software.

The computer system 1100 also includes a communication interface 1117coupled to bus 1101. The communication interface 1117 provides a two-waydata communication coupling to a network link 1119 connected to a localnetwork 1121. For example, the communication interface 1117 may be adigital subscriber line (DSL) card or modem, an integrated servicesdigital network (ISDN) card, a cable modem, a telephone modem, or anyother communication interface to provide a data communication connectionto a corresponding type of communication line. As another example,communication interface 1117 may be a local area network (LAN) card(e.g. for Ethernet™ or an Asynchronous Transfer Model (ATM) network) toprovide a data communication connection to a compatible LAN. Wirelesslinks can also be implemented. In any such implementation, communicationinterface 1117 sends and receives electrical, electromagnetic, oroptical signals that carry digital data streams representing varioustypes of information. Further, the communication interface 1117 caninclude peripheral interface devices, such as a Universal Serial Bus(USB) interface, a PCMCIA (Personal Computer Memory Card InternationalAssociation) interface, etc. Although a single communication interface1117 is depicted in FIG. 11, multiple communication interfaces can alsobe employed.

The network link 1119 typically provides data communication through oneor more networks to other data devices. For example, the network link1119 may provide a connection through local network 1121 to a hostcomputer 1123, which has connectivity to a network 1125 (e.g. a widearea network (WAN) or the global packet data communication network nowcommonly referred to as the “Internet”) or to data equipment operated bya service provider. The local network 1121 and the network 1125 both useelectrical, electromagnetic, or optical signals to convey informationand instructions. The signals through the various networks and thesignals on the network link 1119 and through the communication interface1117, which communicate digital data with the computer system 1100, areexemplary forms of carrier waves bearing the information andinstructions.

The computer system 1100 can send messages and receive data, includingprogram code, through the network(s), the network link 1119, and thecommunication interface 1117. In the Internet example, a server (notshown) might transmit requested code belonging to an application programfor implementing an embodiment of the present invention through thenetwork 1125, the local network 1121 and the communication interface1117. The processor 1103 may execute the transmitted code while beingreceived and/or store the code in the storage device 1109, or othernon-volatile storage for later execution. In this manner, the computersystem 1100 may obtain application code in the form of a carrier wave.

The term “computer-readable medium” as used herein refers to any mediumthat participates in providing instructions to the processor 1103 forexecution. Such a medium may take many forms, including but not limitedto non-volatile media, volatile media, and transmission media.Non-volatile media include, for example, optical or magnetic disks, suchas the storage device 1109. Volatile media include dynamic memory, suchas main memory 1105. Transmission media include coaxial cables, copperwire and fiber optics, including the wires that comprise the bus 1101.Transmission media can also take the form of acoustic, optical, orelectromagnetic waves, such as those generated during radio frequency(RF) and infrared (IR) data communications. Common forms ofcomputer-readable media include, for example, a floppy disk, a flexibledisk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM,CDRW, DVD, any other optical medium, punch cards, paper tape, opticalmark sheets, any other physical medium with patterns of holes or otheroptically recognizable indicia, a RAM, a PROM, and EPROM, a FLASH-EPROM,any other memory chip or cartridge, a carrier wave, or any other mediumfrom which a computer can read.

Various forms of computer-readable media may be involved in providinginstructions to a processor for execution. For example, the instructionsfor carrying out at least part of the present invention may initially beborne on a magnetic disk of a remote computer. In such a scenario, theremote computer loads the instructions into main memory and sends theinstructions over a telephone line using a modem. A modem of a localcomputer system receives the data on the telephone line and uses aninfrared transmitter to convert the data to an infrared signal andtransmit the infrared signal to a portable computing device, such as apersonal digital assistant (PDA) or a laptop. An infrared detector onthe portable computing device receives the information and instructionsborne by the infrared signal and places the data on a bus. The busconveys the data to main memory, from which a processor retrieves andexecutes the instructions. The instructions received by main memory canoptionally be stored on storage device either before or after executionby processor.

The following patent applications are incorporated in their entireties:co-pending U.S. patent application Ser. No. 11/141,373, filed May 31,2005, entitled “Method and Apparatus for Providing Fraud Detection UsingGeographically Differented Connection Duration Thresholds”; co-pendingU.S. patent application Ser. No. 11/141,369, filed May 31, 2005,entitled “Method and Apparatus for Providing Fraud Detection UsingConnection Frequency and Cumulative Duration Thresholds”; co-pendingU.S. patent application Ser. No. 11/141,352, filed May 31, 2005,entitled “Method and System for Prioritizing Cases for Fraud Detection”;and co-pending U.S. patent application Ser. No. 11/141,364, filed May31, 2005, entitled “Method and Apparatus for Providing Fraud DetectionUsing Hot or Cold Originating Attributes.”

While the present invention has been described in connection with anumber of embodiments and implementations, the present invention is notso limited but covers various obvious modifications and equivalentarrangements, which fall within the purview of the appended claims.

1. A method for detecting unauthorized use of data services, the methodcomprising: determining whether connections supporting remote access toa data network are completed; tracking number of completed connectionsassociated with a selected attribute over a time period; determiningwhether the number of completed connections satisfies a connectionfrequency threshold; and generating a fraud alert if the connectionfrequency threshold is satisfied.